home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / hacklist / 94-04.Z / 94-04 / 000010_rcq@mailserv-D.ftp.com_Sat Apr 9 07:28:25 1994.msg < prev    next >
Internet Message Format  |  1994-04-30  |  3KB
  1. Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA01579; Sat, 9 Apr 1994 11:31:45 -0400
  3. Received: from ftp.com by ftp.com  ; Sat, 9 Apr 1994 11:29:30 -0400
  4. Received: from mailserv-D.ftp.com by ftp.com  ; Sat, 9 Apr 1994 11:29:30 -0400
  5. Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
  6.     id AA19987; Sat, 9 Apr 94 11:28:25 EDT
  7. Date: Sat, 9 Apr 94 11:28:25 EDT
  8. Message-Id: <9404091528.AA19987@mailserv-D.ftp.com>
  9. To: winsock-hackers@sunsite.unc.edu
  10. Subject: closesocket()/WSACleanup() question
  11. From: rcq@ftp.com  (Bob Quinn)
  12. Reply-To: rcq@ftp.com
  13. Cc: SawatH@msmailhq.netimage.com
  14. Sender: rcq@mailserv-D.ftp.com
  15. Repository: mailserv-D.ftp.com, [message accepted at Sat Apr  9 11:28:10 1994]
  16. Originating-Client: hurricane.ftp.com
  17. Content-Length: 2573
  18.  
  19. One of our customers recently brought a statement in the documen-
  20. tation for WSACleanup() to my attention.  I am amazed that the
  21. section he quoted made it into the specification at all, let alone
  22. the fact it's never been questioned since.  Here is the customer's
  23. message text (forwarded with his permission):
  24.  
  25. >  I see this as a bug in the implementation.  There shouldn't 
  26. >  be any need to wait for the TCP close to complete before the 
  27. >  call to WSACleanup().  Winsock spec 1.1 said
  28. >  
  29. >       "Any open SOCK_STREAM sockets that are connected when
  30. >  WSACleanup() is called are reset; sockets which have been closed 
  31. >  with closesocket() but which still have pending data to be sent 
  32. >  are not affected--the pending data is still sent."
  33. >  
  34. >  As you see, it explicitly said that in the last statement.  This 
  35. >  is also comfirm by the same behavior in other TCP/IP vendors such 
  36. >  as Lan Workplace, BW, and NetManage.
  37.  
  38. This requirement is inappropriate for a few reasons:
  39.  
  40.   - It's not possible to have a DLL that complies with this 
  41.     requirement, unless it has a seperate process that exists
  42.     independently of the DLL (so it survives the DLL, after a
  43.     process has called WSACleanup() and Windows has called WEP()
  44.     and unloaded the DLL from memory).  Hence, the specification
  45.     is making an unreasonable architectural requirement.
  46.  
  47.   - Since a call to WSACleanup() means an application has severed
  48.     it's communication with the WinSock DLL and stack, there is
  49.     no way for the WinSock to subsequently notify the application
  50.     in the event of a failure. Networks fail sometimes.  Computers 
  51.     do too.  Since the network or remote computer can fail after 
  52.     the application calls WSACleanup(), there is no way a WinSock 
  53.     DLL or stack can absolutely guarantee data delivery or a 
  54.     graceful close.  So, a DLL cannot be faulted if it resets the
  55.     connection when an application calls WSACleanup(), even if
  56.     closesocket() was called before.  The application wouldn't
  57.     know the difference either way.
  58.  
  59. My take on it is that if an application really cares about its
  60. data and/or having a graceful close of the connection, then it
  61. should wait until the socket is closed before calling WSACleanup().
  62. In other words, the onus should be on the application, not on the
  63. WinSock DLL and stack.  This is easily accomplished in an applica-
  64. tion with FD_CLOSE notification, among other methods.
  65.  
  66. Comments?
  67. --
  68.  Bob Quinn                                             rcq@ftp.com
  69.  FTP Software, Inc.                                No. Andover, MA